Skip to main content

Design Handoff Process

Transfer Designs from UX/UI to Frontend Team​

This document outlines the structured process for transferring designs from the UX/UI team to the frontend team. It ensures that technical and user requirements are met while maintaining accessibility standards. By integrating continuous testing and feedback, the process not only enhances the feasibility and inclusivity of the final implementations but also ensures smooth and efficient collaboration between teams.

Process diagram​

Process diagram

Ticket #1​

The UX/UI team begins by collecting technical requirements (1.1). These include calculations, API structures, and functions from relevant technical sources (for example, the CoP for Architecture).
At the same time, requirements from users, the Product Owner, stakeholders, and the community (1.2) are gathered. These focus on content, processes, and perspectives from different user groups.

Based on these inputs, the UX/UI team creates a UX concept (2) in Figma. This concept includes wireframes and prototypes. It is reviewed and discussed in a synchronous feasibility assessment (3.2) meeting with the frontend team to evaluate whether it can be implemented technically. In parallel, the frontend team considers accessibility requirements (3.1) based on WCAG standards.

During this phase, the UX/UI team also performs concept testing. This may take place live with a presentation in front of users or asynchronously through prototype links. Depending on the complexity of topics, screens, and flows, multiple iterations may be required. The feedback flows back into the UX concept.

Ticket #2​

In the second phase, the UX/UI team incorporates accessibility requirements according to WCAG and theming specifications (5).

They continue by producing detailed UI designs (6.1) in Figma. Alongside the screen designs, a component library (6.2) is developed in Figma and maintained as the single source of truth.

Accessibility tests (7.1) are carried out using tools such as the Figma Contrast plugin and internal team reviews (“brain checks”). In addition, usability and accessibility tests (7.2) are performed. These can be synchronous with a certain user group or asynchronous via prototype links. As with concept testing, they may include one or multiple iterations depending on complexity, flows, screens, and specific topics.

Ticket #3​

Next, design tokens are handed over from the UX/UI team to the frontend team. The frontend team then takes over with the development and implementation of screens and components (8.1). These implementations are documented and continuously updated in Storybook (8.2), which serves as a living documentation of the components.

To ensure quality, several accessibility tests are conducted:

  • Accessibility tests in the overall context (10.1) using the IBM Equal Access Accessibility Checker and screen readers checker.
  • Automated accessibility tests (10.2) of the component library through the Storybook UI & Accessibility (a11y) addon.

The implementation is then reviewed by the UX/UI team (11), including accessibility tests in the overall context (12) with the community. These tests are conducted through user testing with individuals who rely on screen readers, and are further supported by tools such as the IBM Equal Access Accessibility Checker.

Based on the results of the review, feedback is implemented (13). This is followed by a second review of the implementation (14).

This process ensures that requirements from both the technical and user perspectives are consistently gathered, validated, tested, and transformed into accessible, feasible, and well-documented frontend implementations.

Additional notes​

  • A ticket can only be considered in sprint planning once the previous stage has been completed